Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support to compile the gazebo executable on Windows #2864

Merged
merged 1 commit into from
Nov 24, 2020
Merged

Add support to compile the gazebo executable on Windows #2864

merged 1 commit into from
Nov 24, 2020

Conversation

traversaro
Copy link
Collaborator

All the versions of Gazebo available on Windows provide the two separate binaries gzserver and gzclient, but do not provide the unified command gazebo that is commonly used by users and in documentation, examples and ROS launch files. This PR add supports for compiling the gazebo command also on Windows.

gazebo_command_windows

To do so, to avoid meddling with the low level Windows CreateProcess API, we used the MIT licensed tiny-process-library. However, this additional dependency is added only on Windows, and by default on Windows is automatically downloaded and compiled using the CMake's FetchContent module, to ensure that all existing Windows documentation and build script will continue to work. To use FetchContent, the minimum required version of CMake on Windows is increment to CMake 3.11, but this should not be on Windows were there is no system-provided CMake and the CMake version installed is quite recent. However, if it is necessary to avoid the use of FetchContent I can vendor tiny-process-library in a more old-style way by simply adding its files in the deps/tiny-process-library directory.

However, a USE_EXTERNAL_TINY_PROCESS_LIBRARY CMake option is added to permit to use a system-provided tiny-process-library, to simplify the life of package maintainers on Windows.

To clarify further, this PR should not influence in any way the behavior of Gazebo on non-Windows platforms.

@traversaro
Copy link
Collaborator Author

If any user is interested in use the gazebo command in an existing installation of Gazebo, I also added it in a standalone repo at https://github.com/traversaro/gazebo-command-windows .

@traversaro
Copy link
Collaborator Author

FYI @seanyen @wolfv @Tobias-Fischer

@traversaro
Copy link
Collaborator Author

traversaro commented Oct 25, 2020 •
edited
Loading

I just realized that the option USE_EXTERNAL_TINY_PROCESS_LIBRARY set to ON can't work as it is, as tiny-process-library does not install the necessary CMake config files. The default USE_EXTERNAL_TINY_PROCESS_LIBRARY set to OFF instead indeed works as expected.

@traversaro traversaro mentioned this pull request Oct 28, 2020
Closed
@j-rivero
Copy link
Contributor

@osrf-jenkins run tests please

@traversaro
Copy link
Collaborator Author

I just realized that the option USE_EXTERNAL_TINY_PROCESS_LIBRARY set to ON can't work as it is, as tiny-process-library does not install the necessary CMake config files. The default USE_EXTERNAL_TINY_PROCESS_LIBRARY set to OFF instead indeed works as expected.

For making the USE_EXTERNAL_TINY_PROCESS_LIBRARY option set to ON work I submitted a PR upstream in tiny-process-library: https://gitlab.com/eidheim/tiny-process-library/-/merge_requests/38 .

@traversaro
Copy link
Collaborator Author

I just realized that the option USE_EXTERNAL_TINY_PROCESS_LIBRARY set to ON can't work as it is, as tiny-process-library does not install the necessary CMake config files. The default USE_EXTERNAL_TINY_PROCESS_LIBRARY set to OFF instead indeed works as expected.

For making the USE_EXTERNAL_TINY_PROCESS_LIBRARY option set to ON work I submitted a PR upstream in tiny-process-library: https://gitlab.com/eidheim/tiny-process-library/-/merge_requests/38 .

The MR has been merged, and this PR has been updated to correctly handle the USE_EXTERNAL_TINY_PROCESS_LIBRARY option.

@j-rivero
Copy link
Contributor

Had some problems with Windows CI infra, running here Build Status

@j-rivero
Copy link
Contributor

Had some problems with Windows CI infra, running here Build Status

Enabling the test_fixture has triggered some linking errors:

  Creating library UNIT_PresetManager_TEST.lib and object UNIT_PresetManager_TEST.exp
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: __cdecl gazebo::Server::Server(void)" (??0Server@gazebo@@QEAA@XZ) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: bool __cdecl gazebo::Server::ParseArgs(int,char * *)" (?ParseArgs@Server@gazebo@@QEAA_NHPEAPEAD@Z) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: void __cdecl gazebo::Server::Run(void)" (?Run@Server@gazebo@@QEAAXXZ) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: void __cdecl gazebo::Server::Stop(void)" (?Stop@Server@gazebo@@QEAAXXZ) referenced in function "protected: virtual void __cdecl gazebo::RenderingFixture::Unload(void)" (?Unload@RenderingFixture@gazebo@@MEAAXXZ)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: void __cdecl gazebo::Server::Fini(void)" (?Fini@Server@gazebo@@QEAAXXZ) referenced in function "protected: void __cdecl gazebo::ServerFixture::RunServer(class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > const &)" (?RunServer@ServerFixture@gazebo@@IEAAXAEBV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Z)
gazebo_test_fixture.lib(ServerFixture.cc.obj) : error LNK2019: unresolved external symbol "public: bool __cdecl gazebo::Server::GetInitialized(void)const " (?GetInitialized@Server@gazebo@@QEBA_NXZ) referenced in function "protected: virtual void __cdecl gazebo::ServerFixture::LoadArgs(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?LoadArgs@ServerFixture@gazebo@@MEAAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
UNIT_PresetManager_TEST.exe : fatal error LNK1120: 6 unresolved externals

@traversaro
Copy link
Collaborator Author

Are this problems related to this CI in particular, or they affect also the gazebo11 branch?

@j-rivero
Copy link
Contributor

Are this problems related to this CI in particular, or they affect also the gazebo11 branch?

I ran a testing build of gazebo11 branch yesterday, seems fine. Seems to me that the error is coming from these lines. I can find a bit of time new week to give it a look if you don't have time before Silvio.

@traversaro
Copy link
Collaborator Author

Interesting, indeed in my compilation I did not enable the Gazebo tests, I can try to check it with conda-provided dependencies.

@traversaro
Copy link
Collaborator Author

I did not find the exact error, but I noticed an error that could be related: basically the libgazebo library output name was set to be gazebo in https://github.com/osrf/gazebo/blob/gazebo11_11.2.0/gazebo/CMakeLists.txt#L106, and that could create problems. I ensure that this was not happening on Windows, and now in my case everything is working fine. I pushed the change, can you try again in your CI @j-rivero ?

@j-rivero
Copy link
Contributor

I did not find the exact error, but I noticed an error that could be related: basically the libgazebo library output name was set to be gazebo in https://github.com/osrf/gazebo/blob/gazebo11_11.2.0/gazebo/CMakeLists.txt#L106, and that could create problems. I ensure that this was not happening on Windows, and now in my case everything is working fine. I pushed the change, can you try again in your CI @j-rivero ?

Bingo: https://build.osrfoundation.org/job/gazebo-ci-pr_any-windows7-amd64/3074/ . Thanks Silvio.

@chapulina chapulina added the 11 Gazebo 11 label Nov 23, 2020
@j-rivero j-rivero merged commit c2cf55a into gazebosim:gazebo11 Nov 24, 2020
This was referenced Nov 25, 2020
Merged
Merged
@traversaro traversaro mentioned this pull request Dec 12, 2020
Closed
@traversaro traversaro mentioned this pull request Feb 25, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@j-rivero j-rivero j-rivero approved these changes

Assignees

@j-rivero j-rivero

Labels
11 Gazebo 11
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@traversaro @j-rivero @chapulina